(A continuation of:
http://marc.info/?l=apache-modperl&m=117507879929572&w=2
http://marc.info/?l=apache-modperl&m=119072925228529&w=2
)

I've just spent many frustrating days debugging a situation that
turned out to be caused by mod_perl's closing of file descriptor 1
(STDOUT).

Here's the reproducible case I ultimately got it down to. Using
mod_perl 2, with a dead-simple configuration and this handler:

use DBI;
sub handler {
my $dbh = DBI->connect( "DBI:mysql:$database", $user, $pass,
{ RaiseError => 1 } );
system('echo "hello"');
eval { $dbh->do("select 1") };
print "dbh - " . ( $ [at] ? "error: $ [at] \n" : "ok" ) . "\n";
return 0;
}

This outputs:

dbh - error: DBD::mysql::db do failed: Lost connection to MySQL
server during query at...

The DBI connection dies because mod_perl closes fd 1 (STDOUT). So the
next open - in this case the remote mysql connection created by DBI -
gets fd 1. The child process created by system() writes innocently to
STDOUT, which goes to our mysql socket, causing havoc.

We can confirm this by inserting this at the beginning of the handler:

sub handler {
open(my $fh, ">/dev/null");
print "fh - " . fileno($fh) . "\n";
...

Now this outputs:

fh - 1
dbh - ok

The initial open grabs fd 1, which means that DBI gets a different fd,
and the connection doesn't die.

Now this example is contrived, but replace 'echo "hello"' with any
innocuous system() or backtick call that accidentally sends a bit of
output to STDOUT, and you can see how this would cause all kinds of
baffling bugs. In my case, it was originally a call to "sendmail" that
intermittently sent a warning to STDOUT, and thus destroyed our first
database connection. It worked fine in mod_perl 1, but started
breaking when we upgraded to mod_perl 2.

Is there really no way to fix this in mod_perl, perhaps by
automatically opening a /dev/null handle as I did above? Other future
developers will surely endure the same hours of frustration I did if
it is left alone.

Thanks
Jon

This never got a response. Which surprises me, since I think it is a
legitimate and nasty bug.

So is the silence because
1) people don't think it's really a bug
2) people glazed over while reading the description
3) ??

Thanks :)
Jon

On Jan 8, 2010, at 6:15 AM, Jonathan Swartz wrote:

> (A continuation of:
> http://marc.info/?l=apache-modperl&m=117507879929572&w=2
> http://marc.info/?l=apache-modperl&m=119072925228529&w=2
> )
>
> I've just spent many frustrating days debugging a situation that
> turned out to be caused by mod_perl's closing of file descriptor 1
> (STDOUT).
>
> Here's the reproducible case I ultimately got it down to. Using
> mod_perl 2, with a dead-simple configuration and this handler:
>
> use DBI;
> sub handler {
> my $dbh = DBI->connect( "DBI:mysql:$database", $user, $pass,
> { RaiseError => 1 } );
> system('echo "hello"');
> eval { $dbh->do("select 1") };
> print "dbh - " . ( $ [at] ? "error: $ [at] \n" : "ok" ) . "\n";
> return 0;
> }
>
> This outputs:
>
> dbh - error: DBD::mysql::db do failed: Lost connection to MySQL
> server during query at...
>
> The DBI connection dies because mod_perl closes fd 1 (STDOUT). So
> the next open - in this case the remote mysql connection created by
> DBI - gets fd 1. The child process created by system() writes
> innocently to STDOUT, which goes to our mysql socket, causing havoc.
>
> We can confirm this by inserting this at the beginning of the handler:
>
> sub handler {
> open(my $fh, ">/dev/null");
> print "fh - " . fileno($fh) . "\n";
> ...
>
> Now this outputs:
>
> fh - 1
> dbh - ok
>
> The initial open grabs fd 1, which means that DBI gets a different
> fd, and the connection doesn't die.
>
> Now this example is contrived, but replace 'echo "hello"' with any
> innocuous system() or backtick call that accidentally sends a bit of
> output to STDOUT, and you can see how this would cause all kinds of
> baffling bugs. In my case, it was originally a call to "sendmail"
> that intermittently sent a warning to STDOUT, and thus destroyed our
> first database connection. It worked fine in mod_perl 1, but started
> breaking when we upgraded to mod_perl 2.
>
> Is there really no way to fix this in mod_perl, perhaps by
> automatically opening a /dev/null handle as I did above? Other
> future developers will surely endure the same hours of frustration I
> did if it is left alone.
>
> Thanks
> Jon
>

On Tue, Jan 26, 2010 at 5:20 PM, Jonathan Swartz <swartz [at] pobox.com> wrote:
> This never got a response. Which surprises me, since I think it is a
> legitimate and nasty bug.
>
> So is the silence because
> 1) people don't think it's really a bug
> 2) people glazed over while reading the description
> 3) ??

4) Don't understand how widespread or common this issue is, or if you
are the only one seeing it.

>
> Thanks :)
> Jon
>
> On Jan 8, 2010, at 6:15 AM, Jonathan Swartz wrote:
>
>> (A continuation of:
>> http://marc.info/?l=3Dapache-modperl&m=3D117507879929572&w=3 D2
>> http://marc.info/?l=3Dapache-modperl&m=3D119072925228529&w=3 D2
>> )
>>
>> I've just spent many frustrating days debugging a situation that turned
>> out to be caused by mod_perl's closing of file descriptor 1 (STDOUT).
>>
>> Here's the reproducible case I ultimately got it down to. Using mod_perl
>> 2, with a dead-simple configuration and this handler:
>>
>> =A0use DBI;
>> =A0sub handler {
>> =A0 =A0 =A0my $dbh =3D DBI->connect( "DBI:mysql:$database", $user, $pass=
, {
>> RaiseError =3D> 1 } );
>> =A0 =A0 =A0system('echo "hello"');
>> =A0 =A0 =A0eval { $dbh->do("select 1") };
>> =A0 =A0 =A0print "dbh - " . ( $ [at] ? "error: $ [at] \n" : "ok" ) . "\n";
>> =A0 =A0 =A0return 0;
>> =A0}
>>
>> This outputs:
>>
>> =A0dbh - error: DBD::mysql::db do failed: Lost connection to MySQL serve=
r
>> during query at...
>>
>> The DBI connection dies because mod_perl closes fd 1 (STDOUT). So the ne=
xt
>> open - in this case the remote mysql connection created by DBI - gets fd=
1.
>> The child process created by system() writes innocently to STDOUT, which
>> goes to our mysql socket, causing havoc.
>>
>> We can confirm this by inserting this at the beginning of the handler:
>>
>> =A0sub handler {
>> =A0 =A0 =A0 open(my $fh, ">/dev/null");
>> =A0 =A0 =A0 print "fh - " . fileno($fh) . "\n";
>> =A0 =A0 =A0 ...
>>
>> Now this outputs:
>>
>> =A0fh - 1
>> =A0dbh - ok
>>
>> The initial open grabs fd 1, which means that DBI gets a different fd, a=
nd
>> the connection doesn't die.
>>
>> Now this example is contrived, but replace 'echo "hello"' with any
>> innocuous system() or backtick call that accidentally sends a bit of out=
put
>> to STDOUT, and you can see how this would cause all kinds of baffling bu=
gs.
>> In my case, it was originally a call to "sendmail" that intermittently s=
ent
>> a warning to STDOUT, and thus destroyed our first database connection. I=
t
>> worked fine in mod_perl 1, but started breaking when we upgraded to mod_=
perl
>> 2.
>>
>> Is there really no way to fix this in mod_perl, perhaps by automatically
>> opening a /dev/null handle as I did above? Other future developers will
>> surely endure the same hours of frustration I did if it is left alone.
>>
>> Thanks
>> Jon
>>
>
>

--Apple-Mail-39--704481328
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii

Dear List-Members,

with interest I found the below thread. Starting in Oct. or Nov. last =
year I am getting a lot of messages in apaches error_log like:

[Fri Feb 5 11:07:09 2010] -e: Software caused connection abort at ...

And it always happen in a print to STDOUT. I notice that it also happen =
with smaller scripts (running under mod_perl) with no database =
connection, i.e. scripts which do the following:

use CGI;
use IO::File;

my $q =3D CGI->new();
print $q->header() . $q->start_html();

my $fp =3D IO::File->new('< /somewhere/');
if ($fp) {
binmode STDOUT;
while (read($fp, $buffer, 1024)) {
print $buffer; # << abort points to here !!!
}
$fh->close();
}
print $q->end_html();

So I am really wondering whats going on here. The above file works for =
years now, has not been touched and the content of the opened files =
isn't empty. The server is a FreeBSD 7.0, apache apache-2.2.14, prefork =
MPM, mod_perl2-2.0.4 everything from a current freebsd ports.

I use a perl-startup script for apache:

---snip--snip---
#/usr/bin/perl

use CGI();
CGI->compile(':all');
use DBI;
DBI->install_driver("mysql");
use Carp;
---snap---snap---

which is loaded within httpd.conf with:

<IfModule mod_perl.c>
PerlWarn On
PerlTaintCheck On
PerlModule Apache::DBI
PerlRequire /usr/local/etc/apache22/perl-startup.pl

<Perl>
use CGI::Carp;
$SIG{__DIE__} =3D sub { confess shift };
$SIG{__WARN__} =3D \&Carp::cluck;
</Perl>

<Files *.pl>
SetHandler perl-script
PerlHandler ModPerl::Registry
Options ExecCGI
PerlSendHeader On
</Files>

</IfModule>

I would appreciate any help or ideas to get rid of the aborts.

Heiko



> On Tue, Jan 26, 2010 at 5:20 PM, Jonathan Swartz <swartz [at] pobox.com> =
wrote:
>> This never got a response. Which surprises me, since I think it is a
>> legitimate and nasty bug.
>>
>> So is the silence because
>> 1) people don't think it's really a bug
>> 2) people glazed over while reading the description
>> 3) ??
>
> 4) Don't understand how widespread or common this issue is, or if you
> are the only one seeing it.
>
>>
>> Thanks :)
>> Jon
>>
>> On Jan 8, 2010, at 6:15 AM, Jonathan Swartz wrote:
>>
>>> (A continuation of:
>>> http://marc.info/?l=3Dapache-modperl&m=3D117507879929572&w=3 D2
>>> http://marc.info/?l=3Dapache-modperl&m=3D119072925228529&w=3 D2
>>> )
>>>
>>> I've just spent many frustrating days debugging a situation that =
turned
>>> out to be caused by mod_perl's closing of file descriptor 1 =
(STDOUT).
>>>
>>> Here's the reproducible case I ultimately got it down to. Using =
mod_perl
>>> 2, with a dead-simple configuration and this handler:
>>>
>>> use DBI;
>>> sub handler {
>>> my $dbh =3D DBI->connect( "DBI:mysql:$database", $user, $pass, =
{
>>> RaiseError =3D> 1 } );
>>> system('echo "hello"');
>>> eval { $dbh->do("select 1") };
>>> print "dbh - " . ( $ [at] ? "error: $ [at] \n" : "ok" ) . "\n";
>>> return 0;
>>> }
>>>
>>> This outputs:
>>>
>>> dbh - error: DBD::mysql::db do failed: Lost connection to MySQL =
server
>>> during query at...
>>>
>>> The DBI connection dies because mod_perl closes fd 1 (STDOUT). So =
the next
>>> open - in this case the remote mysql connection created by DBI - =
gets fd 1.
>>> The child process created by system() writes innocently to STDOUT, =
which
>>> goes to our mysql socket, causing havoc.
>>>
>>> We can confirm this by inserting this at the beginning of the =
handler:
>>>
>>> sub handler {
>>> open(my $fh, ">/dev/null");
>>> print "fh - " . fileno($fh) . "\n";
>>> ...
>>>
>>> Now this outputs:
>>>
>>> fh - 1
>>> dbh - ok
>>>
>>> The initial open grabs fd 1, which means that DBI gets a different =
fd, and
>>> the connection doesn't die.
>>>
>>> Now this example is contrived, but replace 'echo "hello"' with any
>>> innocuous system() or backtick call that accidentally sends a bit of =
output
>>> to STDOUT, and you can see how this would cause all kinds of =
baffling bugs.
>>> In my case, it was originally a call to "sendmail" that =
intermittently sent
>>> a warning to STDOUT, and thus destroyed our first database =
connection. It
>>> worked fine in mod_perl 1, but started breaking when we upgraded to =
mod_perl
>>> 2.
>>>
>>> Is there really no way to fix this in mod_perl, perhaps by =
automatically
>>> opening a /dev/null handle as I did above? Other future developers =
will
>>> surely endure the same hours of frustration I did if it is left =
alone.
>>>
>>> Thanks
>>> Jon
>>>
>>
>>

--Apple-Mail-39--704481328
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
medium; font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: 2; text-align: =
auto; text-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><span class=3D"Apple-style-span" =
style=3D"font-size: medium;">Dear List-Members,</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
"><span class=3D"Apple-style-span" style=3D"font-size: =
medium;"><br></span></div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><span class=3D"Apple-style-span" =
style=3D"font-size: medium;">with interest I found the below thread. =
Starting in Oct. or Nov. last year I am getting a lot of messages in =
apaches error_log like:</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; "><span class=3D"Apple-style-span" =
style=3D"font-size: medium;"><br></span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal Helvetica; "><span =
class=3D"Apple-style-span" style=3D"font-size: medium;">[Fri Feb  5 =
11:07:09 2010] -e: Software caused connection abort at =
....</span></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><span class=3D"Apple-style-span" =
style=3D"font-size: medium;"><br></span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal Helvetica; "><span =
class=3D"Apple-style-span" style=3D"font-size: medium;">And it always =
happen in a print to STDOUT. I notice that it also happen with smaller =
scripts (running under mod_perl) with no database connection, i.e. =
scripts which do the following:</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal Helvetica; "><span =
class=3D"Apple-style-span" style=3D"font-size: =
medium;"><br></span></div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><span class=3D"Apple-style-span" =
style=3D"font-size: medium;">use CGI;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
"><span class=3D"Apple-style-span" style=3D"font-size: medium;">use =
IO::File;</span></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><span class=3D"Apple-style-span" =
style=3D"font-size: medium;"><br></span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal Helvetica; "><span =
class=3D"Apple-style-span" style=3D"font-size: medium;">my $q =3D =
CGI->new();</span></div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><span class=3D"Apple-style-span" =
style=3D"font-size: medium;">print $q->header() . =
$q->start_html();</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; "><span class=3D"Apple-style-span" =
style=3D"font-size: medium;"><br></span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal Helvetica; "><span =
class=3D"Apple-style-span" style=3D"font-size: medium;">my $fp =3D =
IO::File->new('< /somewhere/');</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
"><span class=3D"Apple-style-span" style=3D"font-size: medium;">if ($fp) =
{</span></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><span class=3D"Apple-style-span" =
style=3D"font-size: medium;">  binmode =
STDOUT;</span></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><span class=3D"Apple-style-span" =
style=3D"font-size: medium;">  while (read($fp, $buffer, =
1024)) {</span></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><span class=3D"Apple-style-span" =
style=3D"font-size: medium;">        print =
$buffer;      # << abort points to here =
!!!</span></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><span class=3D"Apple-style-span" =
style=3D"font-size: medium;">    }</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
"><span class=3D"Apple-style-span" style=3D"font-size: =
medium;">   =
 $fh->close();</span></div><div>}</div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal Helvetica; "><span =
class=3D"Apple-style-span" style=3D"font-size: medium; ">print =
$q->end_html();</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; "><span class=3D"Apple-style-span" =
style=3D"font-size: medium;"><br></span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal Helvetica; "><span =
class=3D"Apple-style-span" style=3D"font-size: medium;">So I am really =
wondering whats going on here. The above file works for years now, has =
not been touched and the content of the opened files isn't empty. The =
server is a FreeBSD 7.0, apache apache-2.2.14, prefork =
MPM, mod_perl2-2.0.4 everything from a current freebsd =
ports.</span></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><span class=3D"Apple-style-span" =
style=3D"font-size: medium;"><br></span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal Helvetica; "><span =
class=3D"Apple-style-span" style=3D"font-size: medium;">I use a =
perl-startup script for apache:</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal Helvetica; "><span =
class=3D"Apple-style-span" style=3D"font-size: =
medium;"><br></span></div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><span class=3D"Apple-style-span" =
style=3D"font-size: medium;">---snip--snip---</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
"><span class=3D"Apple-style-span" style=3D"font-size: medium;"><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
"><span class=3D"Apple-style-span" style=3D"font-size: =
medium;">#/usr/bin/perl</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; "><span class=3D"Apple-style-span" =
style=3D"font-size: medium;"><br></span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal Helvetica; "><span =
class=3D"Apple-style-span" style=3D"font-size: medium;">use =
CGI();</span></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><span class=3D"Apple-style-span" =
style=3D"font-size: medium;">CGI->compile(':all');</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
"><span class=3D"Apple-style-span" style=3D"font-size: medium;">use =
DBI;</span></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><span class=3D"Apple-style-span" =
style=3D"font-size: =
medium;">DBI->install_driver("mysql");</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
"><span class=3D"Apple-style-span" style=3D"font-size: medium;">use =
Carp;</span></div><div>---snap---snap---</div><div><br></div><div>which =
is loaded within httpd.conf =
with:</div><div><br></div><div><div><IfModule =
mod_perl.c></div><div>        PerlWarn =
       On</div><div>       =
 PerlTaintCheck  On</div><div>       =
 PerlModule      Apache::DBI</div><div>   =
     PerlRequire     =
/usr/local/etc/apache22/perl-startup.pl</div><div><br></div><div> &nb=
sp;      <Perl></div><div>     =
           use =
CGI::Carp;</div><div>        $SIG{__DIE__} =3D =
sub { confess shift };</div><div>       =
 $SIG{__WARN__} =3D \&Carp::cluck;</div><div>   =
     </Perl></div><div><br></div><div>   =
     <Files *.pl></div><div>     =
           SetHandler     =
 perl-script</div><div>           =
     PerlHandler     =
ModPerl::Registry</div><div>           =
     Options         =
ExecCGI</div><div>               =
 PerlSendHeader  On</div><div>       =
 </Files></div><div><br></div><div></IfModule></div><div>=
<br></div></div><div>I would appreciate any help or ideas to get rid of =
the =
aborts.</div><div><br></div><div>Heiko</div><div><br></div><div><br></div>=
</span></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><span class=3D"Apple-style-span" =
style=3D"font-size: medium; "><br><blockquote type=3D"cite">On Tue, Jan =
26, 2010 at 5:20 PM, Jonathan Swartz <<a =
href=3D"mailto:swartz [at] pobox.com">swartz [at] pobox.com</a>> =
wrote:<br><blockquote type=3D"cite">This never got a response. Which =
surprises me, since I think it is a<br></blockquote><blockquote =
type=3D"cite">legitimate and nasty bug.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">So is the =
silence because<br></blockquote><blockquote type=3D"cite">1) people =
don't think it's really a bug<br></blockquote><blockquote type=3D"cite">2)=
people glazed over while reading the =
description<br></blockquote><blockquote type=3D"cite">3) =
??<br></blockquote><br>4) Don't understand how widespread or common this =
issue is, or if you<br>are the only one seeing it.<br><br><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">Thanks =
:)<br></blockquote><blockquote =
type=3D"cite">Jon<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">On Jan 8, 2010, =
at 6:15 AM, Jonathan Swartz wrote:<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">(A continuation =
of:<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><a =
href=3D"http://marc.info/?l=3Dapache-modperl&m=3D1175078 79929572&w=
=3D2">http://marc.info/?l=3Dapache-modperl&m=3D117507879 929572&w=3D=
2</a><br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><a =
href=3D"http://marc.info/?l=3Dapache-modperl&m=3D1190729 25228529&w=
=3D2">http://marc.info/?l=3Dapache-modperl&m=3D119072925 228529&w=3D=
2</a><br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">)<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">I've just spent many frustrating =
days debugging a situation that =
turned<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">out to be caused by mod_perl's closing of file descriptor =
1 (STDOUT).<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">Here's the reproducible case I =
ultimately got it down to. Using =
mod_perl<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">2, with a dead-simple =
configuration and this handler:<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"> use =
DBI;<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"> sub handler =
{<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">     my $dbh =3D DBI->connect( =
"DBI:mysql:$database", $user, $pass, =
{<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">RaiseError =3D> 1 } =
);<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">     system('echo =
"hello"');<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">     eval { =
$dbh->do("select 1") };<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">     print "dbh - =
" . ( $ [at] ? "error: $ [at] \n" : "ok" ) . =
"\n";<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">     return =
0;<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"> }<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">This =
outputs:<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"> dbh - error: =
DBD::mysql::db do failed: Lost connection to MySQL =
server<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">during query =
at...<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">The DBI connection dies because =
mod_perl closes fd 1 (STDOUT). So the =
next<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">open - in this case the remote mysql connection created by =
DBI - gets fd 1.<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">The child process created by =
system() writes innocently to STDOUT, =
which<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">goes to our mysql socket, causing =
havoc.<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">We can confirm this by inserting =
this at the beginning of the =
handler:<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"> sub handler =
{<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">      open(my $fh, =
">/dev/null");<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">      print "fh - =
" . fileno($fh) . "\n";<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">      =
....<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">Now this =
outputs:<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"> fh - =
1<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"> dbh - ok<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">The initial open grabs fd 1, =
which means that DBI gets a different fd, =
and<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">the connection doesn't =
die.<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">Now this example is contrived, =
but replace 'echo "hello"' with =
any<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">innocuous system() or backtick call that accidentally =
sends a bit of output<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">to STDOUT, and you can see how =
this would cause all kinds of baffling =
bugs.<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">In my case, it was originally a call to "sendmail" that =
intermittently sent<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">a warning to STDOUT, and thus =
destroyed our first database connection. =
It<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">worked fine in mod_perl 1, but started breaking when we =
upgraded to mod_perl<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">2.<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">Is there really no way to fix =
this in mod_perl, perhaps by =
automatically<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">opening a /dev/null handle as I =
did above? Other future developers =
will<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">surely endure the same hours of frustration I did if it is =
left alone.<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">Thanks<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">Jon<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote></blockquote></span></div></div></div></spa=
n></span></div></body></html>=

--Apple-Mail-39--704481328--

Heiko Weber wrote:
> Dear List-Members,
>
> with interest I found the below thread. Starting in Oct. or Nov. last year I am getting a lot of messages in apaches error_log like:
>
> [Fri Feb 5 11:07:09 2010] -e: Software caused connection abort at ...
>
> And it always happen in a print to STDOUT. I notice that it also happen with smaller scripts (running under mod_perl) with no database connection, i.e. scripts which do the following:
>
....

>
> So I am really wondering whats going on here. The above file works for years now, has not been touched and the content of the opened files isn't empty. The server is a FreeBSD 7.0, apache apache-2.2.14, prefork MPM, mod_perl2-2.0.4 everything from a current freebsd ports.
>

This seems to be happening when your server-side module is trying to
send data back to the browser who requested it.
The most common explanation is that, by the time your module tries to
send the answer, the browser connection does not exist anymore, because
the browser (or something in-between the server and browser) closed it.
This happens for example when the user clicks on a link which triggers
your module, then changes his mind and clicks somewhere else (or closes
the window or the browser) before your module has finished sending the
response.
In other words, he hung up on you.

It is quite frequent and nothing to worry about in principle.

Where it would get more worrying, is that it could indicate that your
application is taking too long to send back a result to the user, and
that he's losing patience.
If a user clicks on a link and expects an answer, he will usually wait
only 10-20 seconds maximum before starting to worry. He may then just
click again on the same link, which would have the same effect.

Hi Andr=E9,

I know what you mean, and I can't agree with you - the server response =
time is really low - most pages are finished loading in less 1-2 =
seconds, and the overall load of the server is at a low level. I believe =
there is an issue, maybe something what Jon is talking about, I also =
using some "system()" call's to execute sendmail or sudo tasks, so maybe =
STDOUT really gets closed - I have no idea. I only see the abort =
messages in errorlog very frequent, maybe 3-4 per minute.

Heiko

Am 05.02.2010 um 15:49 schrieb Andr=E9 Warnier:

>
> Heiko Weber wrote:
>> Dear List-Members,
>> with interest I found the below thread. Starting in Oct. or Nov. last =
year I am getting a lot of messages in apaches error_log like:
>> [Fri Feb 5 11:07:09 2010] -e: Software caused connection abort at =
....
>> And it always happen in a print to STDOUT. I notice that it also =
happen with smaller scripts (running under mod_perl) with no database =
connection, i.e. scripts which do the following:
> ...
>
>> So I am really wondering whats going on here. The above file works =
for years now, has not been touched and the content of the opened files =
isn't empty. The server is a FreeBSD 7.0, apache apache-2.2.14, prefork =
MPM, mod_perl2-2.0.4 everything from a current freebsd ports.
>
> This seems to be happening when your server-side module is trying to =
send data back to the browser who requested it.
> The most common explanation is that, by the time your module tries to =
send the answer, the browser connection does not exist anymore, because =
the browser (or something in-between the server and browser) closed it.
> This happens for example when the user clicks on a link which triggers =
your module, then changes his mind and clicks somewhere else (or closes =
the window or the browser) before your module has finished sending the =
response.
> In other words, he hung up on you.
>
> It is quite frequent and nothing to worry about in principle.
>
> Where it would get more worrying, is that it could indicate that your =
application is taking too long to send back a result to the user, and =
that he's losing patience.
> If a user clicks on a link and expects an answer, he will usually wait =
only 10-20 seconds maximum before starting to worry. He may then just =
click again on the same link, which would have the same effect.

On 02/05/2010 12:16 PM, Heiko Weber wrote:
> Hi André,
>
> I know what you mean, and I can't agree with you - the server response time is really low - most pages are finished loading in less 1-2 seconds, and the overall load of the server is at a low level. I believe there is an issue, maybe something what Jon is talking about, I also using some "system()" call's to execute sendmail or sudo tasks, so maybe STDOUT really gets closed - I have no idea. I only see the abort messages in errorlog very frequent, maybe 3-4 per minute.
>
> Heiko
>
Of course STDOUT, STDIN, and STDERR get closed, not by mod_perl but by
apache. Every UNIX process when demonized must close them to detach
from its controling terminal.

Apache reopens STDERR to its log file, but STDOUT and STDIN remain closed.

Maybe de confusion arises from the fact that when executing a CGI the
server connects them to the client socket, but in mod_perl you are in
the deamon process space.

Please check "Advanced Programing in the UNIX environment", chapter 13:
"Daemon processes" by W. Richard Stevens.

Regards.

Salvador.

--Apple-Mail-2-411306681
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=iso-8859-1

Salvador,

to avoid such issues my "external" tasks don't use STDOUT, STDIN or =
STDERR. They take their parameters from control files and write their =
results back to a status file. This tasks don't send any output back to =
the browsers. As I said, usually some "sudo's to change some system =
settings.

Well, I could replace all system() calls and just store the task jobs =
into a database table, to schedule a background job with cron to check =
and complete this tasks, but then I lost the immediately feedback to the =
user/browser ... AND this is a lot of work for me - unless I can =
exactly repeat the issue I am not sure if it is worth to try it.

Currently it feels to me like a "leakage", sometimes a =
httpd/mod_perl/process do something, and later (maybe when working on =
the next client request) STDOUT is closed. This makes it hard to create =
a sample program to repeat it. Within a single script I can do almost =
everything: call system(), open DBI connections, write to STDOUT, ... =
everything seems to be fine.

Heiko

Am 16.02.2010 um 23:26 schrieb Salvador Ortiz Garcia:

> On 02/05/2010 12:16 PM, Heiko Weber wrote:
>> Hi Andr=E9,
>>
>> I know what you mean, and I can't agree with you - the server =
response time is really low - most pages are finished loading in less =
1-2 seconds, and the overall load of the server is at a low level. I =
believe there is an issue, maybe something what Jon is talking about, I =
also using some "system()" call's to execute sendmail or sudo tasks, so =
maybe STDOUT really gets closed - I have no idea. I only see the abort =
messages in errorlog very frequent, maybe 3-4 per minute.
>>
>> Heiko
>>
> Of course STDOUT, STDIN, and STDERR get closed, not by mod_perl but by =
apache. Every UNIX process when demonized must close them to detach =
from its controling terminal.
>
> Apache reopens STDERR to its log file, but STDOUT and STDIN remain =
closed.
>
> Maybe de confusion arises from the fact that when executing a CGI the =
server connects them to the client socket, but in mod_perl you are in =
the deamon process space.
>
> Please check "Advanced Programing in the UNIX environment", chapter =
13: "Daemon processes" by W. Richard Stevens.
>
> Regards.
>
> Salvador.

--
Wecos <> Heiko Weber Computer Systeme
D-21644 Sauensiek <> Immenweg 5
heiko [at] wecos.de <> http://www.wecos.de
Tel. +49 (4169) 91000 <> Fax +49 (4169) 919033
____________________________________________________________ ___
This email may contain confidential and privileged material for
the sole use of the intended recipient. Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient please contact the sender and delete all copies.
____________________________________________________________ ___
Diese E-Mail kann digital signiert sein. Falls Ihr E-Mail-Programm
nicht ueber die notwendigen Prueffunktionen verfuegt, ignorieren
Sie bitte die angehaengte Signatur-Datei.
____________________________________________________________ ___
This email may be digitally signed. If your email software does
not support the necessary validation feature, please disregard the
attached signature file.
____________________________________________________________ ___


--Apple-Mail-2-411306681
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=iso-8859-1

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
">Salvador,<div><br></div><div>to avoid such issues my "external" tasks =
don't use STDOUT, STDIN or STDERR. They take their parameters from =
control files and write their results back to a status file. This tasks =
don't send any output back to the browsers. As I said, usually some =
"sudo's to change some system =
settings. </div><div><br></div><div>Well, I could replace all =
system() calls and just store the task jobs into a database table, to =
schedule a background job with cron to check and complete this tasks, =
but then I lost the immediately feedback to the user/browser ... AND =
this is a lot of work for me -  unless I can exactly repeat the =
issue I am not sure if it is worth to try =
it.</div><div><br></div><div>Currently it feels to me like a "leakage", =
sometimes a httpd/mod_perl/process do something, and later (maybe when =
working on the next client request) STDOUT is closed. This makes it hard =
to create a sample program to repeat it. Within a single script I can do =
almost everything: call system(), open DBI connections, write to STDOUT, =
.... everything seems to be =
fine.</div><div><br></div><div>Heiko</div><div><br><div><div>Am =
16.02.2010 um 23:26 schrieb Salvador Ortiz Garcia:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div>On =
02/05/2010 12:16 PM, Heiko Weber wrote:<br><blockquote type=3D"cite">Hi =
Andr=E9,<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">I know what you =
mean, and I can't agree with you - the server response time is really =
low - most pages are finished loading in less 1-2 seconds, and the =
overall load of the server is at a low level. I believe there is an =
issue, maybe something what Jon is talking about, I also using some =
"system()" call's to execute sendmail or sudo tasks, so maybe STDOUT =
really gets closed - I have no idea. I only see the abort messages in =
errorlog very frequent, maybe 3-4 per =
minute.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">Heiko<br></blockquote><blockquote type=3D"cite"> =
  <br></blockquote>Of course STDOUT, STDIN, and STDERR get =
closed, not by mod_perl but by apache. Every UNIX  process when =
demonized must close them to detach from its controling =
terminal.<br><br>Apache reopens STDERR to its log file, but STDOUT and =
STDIN remain closed.<br><br>Maybe de confusion arises from the fact that =
when executing a CGI the server connects them to the client socket, but =
in mod_perl you are in the deamon process space.<br><br>Please check =
"Advanced Programing in the UNIX environment", chapter 13: "Daemon =
processes" by W. Richard =
Stevens.<br><br>Regards.<br><br>Salvador.<br></div></blockquote></div><br>=
<div>
<span class=3D"Apple-style-span" style=3D"border-collapse: separate; =
color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: 2; text-align: =
auto; text-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; ">-- <br>Wecos <> Heiko Weber Computer =
Systeme<br>D-21644 Sauensiek <> Immenweg 5<br><a =
href=3D"mailto:heiko [at] wecos.de">heiko [at] wecos.de</a> <> <a =
href=3D"http://www.wecos.de/">http://www.wecos.de</a><br>Tel. +49 (4169) =
91000 <> Fax +49 (4169) =
919033<br> ____________________________________________________________ ___<=
br>This email may contain confidential and privileged material =
for<br>the sole use of the intended recipient. Any review or =
distribution<br>by others is strictly prohibited. If you are not the =
intended<br>recipient please contact the sender and delete all =
copies.<br> ____________________________________________________________ ___=
<br>Diese E-Mail kann digital signiert sein. Falls Ihr =
E-Mail-Programm<br>nicht ueber die notwendigen Prueffunktionen verfuegt, =
ignorieren<br>Sie bitte die angehaengte =
Signatur-Datei.<br>_______________________________________________________=
________<br>This email may be digitally signed. If your email software =
does<br>not support the necessary validation feature, please disregard =
the<br>attached signature =
file.<br> ____________________________________________________________ ___<b=
r></div></div></div></span></span>
</div>
<br></div></body></html>=

--Apple-Mail-2-411306681--

--_000_B0011508DF5C184ABEC7A8978D7AB5E80ADADB5CA5NYKPCMMGMB0 3I_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I'm starting to use Gearman to get around this whole problem. We use a l=
ot of external processes for many things, so this issue wtih Apache2 real=
ly bit me hard in the bee-hind. I've gone to great lengths to work aroun=
d it, but so far the job queue approach seems to be the most elegant and =
least problematic approach. Of course, the recommendation came from the =
gentle folks on this list originally.

Eric

________________________________
From: Heiko Weber [mailto:heiko [at] wecos.de]
Sent: Thursday, February 18, 2010 3:22 AM
To: Salvador Ortiz Garcia
Cc: mod_perl list
Subject: Re: [mp2] mod_perl closes apache's stdin and/or stdout

Salvador,

to avoid such issues my "external" tasks don't use STDOUT, STDIN or STDER=
R. They take their parameters from control files and write their results =
back to a status file. This tasks don't send any output back to the brows=
ers. As I said, usually some "sudo's to change some system settings.

Well, I could replace all system() calls and just store the task jobs int=
o a database table, to schedule a background job with cron to check and c=
omplete this tasks, but then I lost the immediately feedback to the user/=
browser ... AND this is a lot of work for me - unless I can exactly repe=
at the issue I am not sure if it is worth to try it.

Currently it feels to me like a "leakage", sometimes a httpd/mod_perl/pro=
cess do something, and later (maybe when working on the next client reque=
st) STDOUT is closed. This makes it hard to create a sample program to re=
peat it. Within a single script I can do almost everything: call system()=
, open DBI connections, write to STDOUT, ... everything seems to be fine.=


Heiko

Am 16.02.2010 um 23:26 schrieb Salvador Ortiz Garcia:

On 02/05/2010 12:16 PM, Heiko Weber wrote:
Hi Andr=E9,

I know what you mean, and I can't agree with you - the server response ti=
me is really low - most pages are finished loading in less 1-2 seconds, a=
nd the overall load of the server is at a low level. I believe there is a=
n issue, maybe something what Jon is talking about, I also using some "sy=
stem()" call's to execute sendmail or sudo tasks, so maybe STDOUT really =
gets closed - I have no idea. I only see the abort messages in errorlog v=
ery frequent, maybe 3-4 per minute.

Heiko

Of course STDOUT, STDIN, and STDERR get closed, not by mod_perl but by ap=
ache. Every UNIX process when demonized must close them to detach from i=
ts controling terminal.

Apache reopens STDERR to its log file, but STDOUT and STDIN remain closed=
..

Maybe de confusion arises from the fact that when executing a CGI the ser=
ver connects them to the client socket, but in mod_perl you are in the de=
amon process space.

Please check "Advanced Programing in the UNIX environment", chapter 13: "=
Daemon processes" by W. Richard Stevens.

Regards.

Salvador.

--
Wecos <> Heiko Weber Computer Systeme
D-21644 Sauensiek <> Immenweg 5
heiko [at] wecos.de<mailto:heiko [at] wecos.de> <> http://www.wecos.de<http://www.w=
ecos.de/>

_______________________________________________

This e-mail may contain information that is confidential, privileged or o=
therwise protected from disclosure. If you are not an intended recipient =
of this e-mail, do not duplicate or redistribute it by any means. Please =
delete it and any attachments and notify the sender that you have receive=
d it in error. Unless specifically indicated, this e-mail is not an offer=
to buy or sell or a solicitation to buy or sell any securities, invest=
ment products or other financial product or service, an official confirma=
tion of any transaction, or an official statement of Barclays. Any views =
or opinions presented are solely those of the author and do not necessari=
ly represent those of Barclays. This e-mail is subject to terms available=
at the following link: www.barcap.com/emaildisclaimer. By messaging wi=
th Barclays you consent to the foregoing. Barclays Capital is the invest=
ment banking division of Barclays Bank PLC, a company registered in Engla=
nd (number 1026167) with its registered office at 1 Churchill Place, Lond=
on, E14 5HP. This email may relate to or be sent from other members of t=
he Barclays Group.
_______________________________________________

--_000_B0011508DF5C184ABEC7A8978D7AB5E80ADADB5CA5NYKPCMMGMB0 3I_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-=
1">
<META content=3D"MSHTML 6.00.2900.3660" name=3DGENERATOR></HEAD>
<BODY
style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; webkit-line-brea=
k: after-white-space">
<DIV dir=3Dltr align=3Dleft><SPAN class=3D688522216-18022010><FONT face=3D=
Arial
color=3D#0000ff size=3D2>I'm starting to use Gearman to get around this w=
hole
problem.  We use a lot of external processes for many things, so thi=
s issue
wtih Apache2 really bit me hard in the bee-hind.  I've gone to great=

lengths to work around it, but so far the job queue approach seems to be =
the
most elegant and least problematic approach.  Of course, the recomme=
ndation
came from the gentle folks on this list originally.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D688522216-18022010><FONT face=3D=
Arial
color=3D#0000ff size=3D2></FONT></SPAN> </DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D688522216-18022010><FONT face=3D=
Arial
color=3D#0000ff size=3D2>Eric</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px so=
lid; MARGIN-RIGHT: 0px">
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft=
>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Heiko Weber [mailto:heiko [at] w=
ecos.de]
<BR><B>Sent:</B> Thursday, February 18, 2010 3:22 AM<BR><B>To:</B> Sa=
lvador
Ortiz Garcia<BR><B>Cc:</B> mod_perl list<BR><B>Subject:</B> Re: [mp2]=
mod_perl
closes apache's stdin and/or stdout<BR></FONT><BR></DIV>
<DIV></DIV>Salvador,
<DIV><BR></DIV>
<DIV>to avoid such issues my "external" tasks don't use STDOUT, STDIN=
or
STDERR. They take their parameters from control files and write their=
results
back to a status file. This tasks don't send any output back to the b=
rowsers.
As I said, usually some "sudo's to change some system settings. =
</DIV>
<DIV><BR></DIV>
<DIV>Well, I could replace all system() calls and just store the task=
jobs
into a database table, to schedule a background job with cron to chec=
k and
complete this tasks, but then I lost the immediately feedback to the =

user/browser ... AND this is a lot of work for me -  unless I ca=
n exactly
repeat the issue I am not sure if it is worth to try it.</DIV>
<DIV><BR></DIV>
<DIV>Currently it feels to me like a "leakage", sometimes a
httpd/mod_perl/process do something, and later (maybe when working on=
the next
client request) STDOUT is closed. This makes it hard to create a samp=
le
program to repeat it. Within a single script I can do almost everythi=
ng: call
system(), open DBI connections, write to STDOUT, ... everything seems=
to be
fine.</DIV>
<DIV><BR></DIV>
<DIV>Heiko</DIV>
<DIV><BR>
<DIV>
<DIV>Am 16.02.2010 um 23:26 schrieb Salvador Ortiz Garcia:</DIV><BR
class=3DApple-interchange-newline>
<BLOCKQUOTE type=3D"cite">
<DIV>On 02/05/2010 12:16 PM, Heiko Weber wrote:<BR>
<BLOCKQUOTE type=3D"cite">Hi Andr=E9,<BR></BLOCKQUOTE>
<BLOCKQUOTE type=3D"cite"><BR></BLOCKQUOTE>
<BLOCKQUOTE type=3D"cite">I know what you mean, and I can't agree w=
ith you -
the server response time is really low - most pages are finished =
loading
in less 1-2 seconds, and the overall load of the server is at a l=
ow level.
I believe there is an issue, maybe something what Jon is talking =
about, I
also using some "system()" call's to execute sendmail or sudo tas=
ks, so
maybe STDOUT really gets closed - I have no idea. I only see the =
abort
messages in errorlog very frequent, maybe 3-4 per minute.<BR></BL=
OCKQUOTE>
<BLOCKQUOTE type=3D"cite"><BR></BLOCKQUOTE>
<BLOCKQUOTE type=3D"cite">Heiko<BR></BLOCKQUOTE>
<BLOCKQUOTE type=3D"cite">  <BR></BLOCKQUOTE>Of course ST=
DOUT,
STDIN, and STDERR get closed, not by mod_perl but by apache. Every =
UNIX
 process when demonized must close them to detach from its con=
troling
terminal.<BR><BR>Apache reopens STDERR to its log file, but STDOUT =
and STDIN
remain closed.<BR><BR>Maybe de confusion arises from the fact that =
when
executing a CGI the server connects them to the client socket, but =
in
mod_perl you are in the deamon process space.<BR><BR>Please check "=
Advanced
Programing in the UNIX environment", chapter 13: "Daemon processes"=
by W.
Richard
Stevens.<BR><BR>Regards.<BR><BR>Salvador.<BR></DIV></BLOCKQUOTE></DIV=
><BR>
<DIV><SPAN class=3DApple-style-span
style=3D"WORD-SPACING: 0px; FONT: medium Helvetica; TEXT-TRANSFORM: n=
one; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPA=
CING: normal; BORDER-COLLAPSE: separate; orphans: 2; widows: 2; webkit-bo=
rder-horizontal-spacing: 0px; webkit-border-vertical-spacing: 0px; webkit=
-text-decorations-in-effect: none; webkit-text-size-adjust: auto; webkit-=
text-stroke-width: 0px"><SPAN
class=3DApple-style-span
style=3D"WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: non=
e; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACI=
NG: normal; BORDER-COLLAPSE: separate; orphans: 2; widows: 2; webkit-bord=
er-horizontal-spacing: 0px; webkit-border-vertical-spacing: 0px; webkit-t=
ext-decorations-in-effect: none; webkit-text-size-adjust: auto; webkit-te=
xt-stroke-width: 0px">
<DIV
style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; webkit-line-=
break: after-white-space">
<DIV>
<DIV style=3D"MARGIN: 0px; FONT: 12px Helvetica">-- <BR>Wecos &l=
t;>
Heiko Weber Computer Systeme<BR>D-21644 Sauensiek <> Immenweg 5=
<BR><A
href=3D"mailto:heiko [at] wecos.de">heiko [at] wecos.de</A> <> <A
href=3D"http://www.wecos.de/">http://www.wecos.de</A></DIV></DIV></DI=
V></SPAN></SPAN></DIV></DIV></BLOCKQUOTE>
<FONT face=3DArial size=3D2>
<P class=3DMsoNormal
style=3D"MARGIN: 0in 0in 0pt; mso-layout-grid-align: none"><SPAN
style=3D"FONT-SIZE: 11pt"><FONT
face=3D"Times New Roman">_______________________________________________<=
?xml:namespace
prefix =3D o ns =3D "urn:schemas-microsoft-com:office:office"
/><o:p></o:p></FONT></SPAN></P>
<P class=3DMsoNormal
style=3D"MARGIN: 0in 0in 0pt; mso-layout-grid-align: none"><SPAN
style=3D"FONT-SIZE: 11pt"><o:p><FONT
face=3D"Times New Roman"> </FONT></o:p></SPAN></P>
<P class=3DMsoNormal
style=3D"MARGIN: 0in 0in 0pt; mso-layout-grid-align: none"><SPAN
style=3D"FONT-SIZE: 11pt"><FONT face=3D"Times New Roman">This e-mail may =
contain
information that is confidential, privileged or otherwise protected from =

disclosure. If you are not an intended recipient of this e-mail, do not
duplicate or redistribute it by any means. Please delete it and any attac=
hments
and notify the sender that you have received it in error. Unless specific=
ally
indicated, this e-mail is not an offer to buy or sell or a solicitation t=
o buy
or sell any securities, investment products or other financial product or=

service, an official confirmation of any transaction, or an official stat=
ement
of Barclays. Any views or opinions presented are solely those of the auth=
or and
do not necessarily represent those of Barclays. This e-mail is subject to=
terms
available at the following link: </FONT></SPAN><SPAN lang=3DEN-GB
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial; mso-ansi-langu=
age: EN-GB; mso-fareast-language: EN-GB"><A
href=3D"http://www.barcap.com/emaildisclaimer">www.barcap.co m/emaildiscla=
imer</A>.
</SPAN><SPAN style=3D"FONT-SIZE: 11pt"><FONT face=3D"Times New Roman">By =
messaging
with Barclays you consent to the foregoing.<SPAN
style=3D"mso-spacerun: yes">  </SPAN>Barclays Capital is the investm=
ent
banking division of Barclays Bank PLC, a company registered in <?xml:name=
space
prefix =3D st1 ns =3D "urn:schemas-microsoft-com:office:smarttags" /><st1=
:place
w:st=3D"on"><st1:country-region w:st=3D"on">England</st1:country-region><=
/st1:place>
(number 1026167) with its registered office at <st1:address
w:st=3D"on"><st1:Street w:st=3D"on">1 Churchill Place</st1:Street>, <st1:=
City
w:st=3D"on">London</st1:City>, <st1:PostalCode w:st=3D"on">E14
5HP</st1:PostalCode></st1:address>.<SPAN style=3D"mso-spacerun: yes">&nbs=
p;
</SPAN>This email may relate to or be sent from other members of the Barc=
lays
Group.<I style=3D"mso-bidi-font-style: normal"><o:p></o:p></I></FONT></SP=
AN></P>
<P class=3DMsoNormal
style=3D"MARGIN: 0in 0in 0pt; mso-layout-grid-align: none"><SPAN
style=3D"FONT-SIZE: 11pt"><FONT
face=3D"Times New Roman">_______________________________________________<=
/FONT></SPAN></FONT></P>
</BODY></HTML>

--_000_B0011508DF5C184ABEC7A8978D7AB5E80ADADB5CA5NYKPCMMGMB0 3I_--

--Apple-Mail-14-455376385
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=iso-8859-1

Wow, thanks Eric ! That seems to be very nice, I'll give it a try and =
will report later here if avoiding system() calls reduce the number of =
aborted connections.

Heiko

Am 18.02.2010 um 17:24 schrieb eric.berg [at] barclayscapital.com:

> I'm starting to use Gearman to get around this whole problem. We use =
a lot of external processes for many things, so this issue wtih Apache2 =
really bit me hard in the bee-hind. I've gone to great lengths to work =
around it, but so far the job queue approach seems to be the most =
elegant and least problematic approach. Of course, the recommendation =
came from the gentle folks on this list originally.
>
> Eric
>
> From: Heiko Weber [mailto:heiko [at] wecos.de]
> Sent: Thursday, February 18, 2010 3:22 AM
> To: Salvador Ortiz Garcia
> Cc: mod_perl list
> Subject: Re: [mp2] mod_perl closes apache's stdin and/or stdout
>
> Salvador,
>
> to avoid such issues my "external" tasks don't use STDOUT, STDIN or =
STDERR. They take their parameters from control files and write their =
results back to a status file. This tasks don't send any output back to =
the browsers. As I said, usually some "sudo's to change some system =
settings.
>
> Well, I could replace all system() calls and just store the task jobs =
into a database table, to schedule a background job with cron to check =
and complete this tasks, but then I lost the immediately feedback to the =
user/browser ... AND this is a lot of work for me - unless I can =
exactly repeat the issue I am not sure if it is worth to try it.
>
> Currently it feels to me like a "leakage", sometimes a =
httpd/mod_perl/process do something, and later (maybe when working on =
the next client request) STDOUT is closed. This makes it hard to create =
a sample program to repeat it. Within a single script I can do almost =
everything: call system(), open DBI connections, write to STDOUT, ... =
everything seems to be fine.
>
> Heiko
>
> Am 16.02.2010 um 23:26 schrieb Salvador Ortiz Garcia:
>
>> On 02/05/2010 12:16 PM, Heiko Weber wrote:
>>> Hi Andr=E9,
>>>
>>> I know what you mean, and I can't agree with you - the server =
response time is really low - most pages are finished loading in less =
1-2 seconds, and the overall load of the server is at a low level. I =
believe there is an issue, maybe something what Jon is talking about, I =
also using some "system()" call's to execute sendmail or sudo tasks, so =
maybe STDOUT really gets closed - I have no idea. I only see the abort =
messages in errorlog very frequent, maybe 3-4 per minute.
>>>
>>> Heiko
>>>
>> Of course STDOUT, STDIN, and STDERR get closed, not by mod_perl but =
by apache. Every UNIX process when demonized must close them to detach =
from its controling terminal.
>>
>> Apache reopens STDERR to its log file, but STDOUT and STDIN remain =
closed.
>>
>> Maybe de confusion arises from the fact that when executing a CGI the =
server connects them to the client socket, but in mod_perl you are in =
the deamon process space.
>>
>> Please check "Advanced Programing in the UNIX environment", chapter =
13: "Daemon processes" by W. Richard Stevens.
>>
>> Regards.
>>
>> Salvador.
>
> --
> Wecos <> Heiko Weber Computer Systeme
> D-21644 Sauensiek <> Immenweg 5
> heiko [at] wecos.de <> http://www.wecos.de
> _______________________________________________
>
> This e-mail may contain information that is confidential, privileged =
or otherwise protected from disclosure. If you are not an intended =
recipient of this e-mail, do not duplicate or redistribute it by any =
means. Please delete it and any attachments and notify the sender that =
you have received it in error. Unless specifically indicated, this =
e-mail is not an offer to buy or sell or a solicitation to buy or sell =
any securities, investment products or other financial product or =
service, an official confirmation of any transaction, or an official =
statement of Barclays. Any views or opinions presented are solely those =
of the author and do not necessarily represent those of Barclays. This =
e-mail is subject to terms available at the following link: =
www.barcap.com/emaildisclaimer. By messaging with Barclays you consent =
to the foregoing. Barclays Capital is the investment banking division =
of Barclays Bank PLC, a company registered in England (number 1026167) =
with its registered office at 1 Churchill Place, London, E14 5HP. This =
email may relate to or be sent from other members of the Barclays Group.
> _______________________________________________

--
Wecos <> Heiko Weber Computer Systeme
D-21644 Sauensiek <> Immenweg 5
heiko [at] wecos.de <> http://www.wecos.de
Tel. +49 (4169) 91000 <> Fax +49 (4169) 919033
____________________________________________________________ ___
This email may contain confidential and privileged material for
the sole use of the intended recipient. Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient please contact the sender and delete all copies.
____________________________________________________________ ___
Diese E-Mail kann digital signiert sein. Falls Ihr E-Mail-Programm
nicht ueber die notwendigen Prueffunktionen verfuegt, ignorieren
Sie bitte die angehaengte Signatur-Datei.
____________________________________________________________ ___
This email may be digitally signed. If your email software does
not support the necessary validation feature, please disregard the
attached signature file.
____________________________________________________________ ___


--Apple-Mail-14-455376385
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=iso-8859-1

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Wow, =
thanks Eric ! That seems to be very nice, I'll give it a try and will =
report later here if avoiding system() calls reduce the number of =
aborted connections.<div><br></div><div>Heiko</div><div><br><div><div>Am =
18.02.2010 um 17:24 schrieb <a =
href=3D"mailto:eric.berg [at] barclayscapital.com">eric.berg [at] barc layscapital.co=
m</a>:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">
<div style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; =
webkit-line-break: after-white-space">
<div dir=3D"ltr" align=3D"left"><span class=3D"688522216-18022010"><font =
face=3D"Arial" color=3D"#0000ff" size=3D"2">I'm starting to use Gearman =
to get around this whole
problem.  We use a lot of external processes for many things, so =
this issue
wtih Apache2 really bit me hard in the bee-hind.  I've gone to =
great
lengths to work around it, but so far the job queue approach seems to be =
the
most elegant and least problematic approach.  Of course, the =
recommendation
came from the gentle folks on this list originally.</font></span></div>
<div dir=3D"ltr" align=3D"left"><span class=3D"688522216-18022010"><font =
face=3D"Arial" color=3D"#0000ff" size=3D"2"></font></span> </div>
<div dir=3D"ltr" align=3D"left"><span class=3D"688522216-18022010"><font =
face=3D"Arial" color=3D"#0000ff" size=3D"2">Eric</font></span></div><br>
<blockquote dir=3D"ltr" style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<div class=3D"OutlookMessageHeader" lang=3D"en-us" dir=3D"ltr" =
align=3D"left">
<hr tabindex=3D"-1">
<font face=3D"Tahoma" size=3D"2"><b>From:</b> Heiko Weber =
[mailto:heiko [at] wecos.de]
<br><b>Sent:</b> Thursday, February 18, 2010 3:22 AM<br><b>To:</b> =
Salvador
Ortiz Garcia<br><b>Cc:</b> mod_perl list<br><b>Subject:</b> Re: [mp2] =
mod_perl
closes apache's stdin and/or stdout<br></font><br></div>
<div></div>Salvador,
<div><br></div>
<div>to avoid such issues my "external" tasks don't use STDOUT, STDIN =
or
STDERR. They take their parameters from control files and write their =
results
back to a status file. This tasks don't send any output back to the =
browsers.
As I said, usually some "sudo's to change some system =
settings. </div>
<div><br></div>
<div>Well, I could replace all system() calls and just store the task =
jobs
into a database table, to schedule a background job with cron to check =
and
complete this tasks, but then I lost the immediately feedback to the =

user/browser ... AND this is a lot of work for me -  unless I can =
exactly
repeat the issue I am not sure if it is worth to try it.</div>
<div><br></div>
<div>Currently it feels to me like a "leakage", sometimes a
httpd/mod_perl/process do something, and later (maybe when working on =
the next
client request) STDOUT is closed. This makes it hard to create a =
sample
program to repeat it. Within a single script I can do almost =
everything: call
system(), open DBI connections, write to STDOUT, ... everything seems =
to be
fine.</div>
<div><br></div>
<div>Heiko</div>
<div><br>
<div>
<div>Am 16.02.2010 um 23:26 schrieb Salvador Ortiz Garcia:</div><br =
class=3D"Apple-interchange-newline">
<blockquote type=3D"cite">
<div>On 02/05/2010 12:16 PM, Heiko Weber wrote:<br>
<blockquote type=3D"cite">Hi Andr=E9,<br></blockquote>
<blockquote type=3D"cite"><br></blockquote>
<blockquote type=3D"cite">I know what you mean, and I can't agree =
with you -
the server response time is really low - most pages are finished =
loading
in less 1-2 seconds, and the overall load of the server is at a =
low level.
I believe there is an issue, maybe something what Jon is talking =
about, I
also using some "system()" call's to execute sendmail or sudo =
tasks, so
maybe STDOUT really gets closed - I have no idea. I only see the =
abort
messages in errorlog very frequent, maybe 3-4 per =
minute.<br></blockquote>
<blockquote type=3D"cite"><br></blockquote>
<blockquote type=3D"cite">Heiko<br></blockquote>
<blockquote type=3D"cite">  <br></blockquote>Of course =
STDOUT,
STDIN, and STDERR get closed, not by mod_perl but by apache. Every =
UNIX
 process when demonized must close them to detach from its =
controling
terminal.<br><br>Apache reopens STDERR to its log file, but STDOUT =
and STDIN
remain closed.<br><br>Maybe de confusion arises from the fact that =
when
executing a CGI the server connects them to the client socket, but =
in
mod_perl you are in the deamon process space.<br><br>Please check =
"Advanced
Programing in the UNIX environment", chapter 13: "Daemon processes" =
by W.
Richard
=
Stevens.<br><br>Regards.<br><br>Salvador.<br></div></blockquote></div><br>=

<div><span class=3D"Apple-style-span" style=3D"word-spacing: 0px; =
font: normal normal normal medium/normal Helvetica; text-transform: =
none; text-indent: 0px; white-space: normal; letter-spacing: normal; =
border-collapse: separate; orphans: 2; widows: 2; "><span =
class=3D"Apple-style-span" style=3D"word-spacing: 0px; font: normal =
normal normal 12px/normal Helvetica; text-transform: none; text-indent: =
0px; white-space: normal; letter-spacing: normal; border-collapse: =
separate; orphans: 2; widows: 2; ">
<div style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; =
webkit-line-break: after-white-space">
<div>
<div style=3D"MARGIN: 0px; FONT: 12px Helvetica">-- <br>Wecos =
<>
Heiko Weber Computer Systeme<br>D-21644 Sauensiek <> Immenweg =
5<br><a href=3D"mailto:heiko [at] wecos.de">heiko [at] wecos.de</a> =
<> <a =
href=3D"http://www.wecos.de/">http://www.wecos.de</a></div></div></div></s=
pan></span></div></div></blockquote>
<font face=3D"Arial" size=3D"2"><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0pt; margin-left: 0in; "><span =
style=3D"FONT-SIZE: 11pt"><font face=3D"Times New =
Roman">_______________________________________________<o:p></o:p></font></=
span></div><div style=3D"margin-top: 0in; margin-right: 0in; =
margin-bottom: 0pt; margin-left: 0in; "><span style=3D"FONT-SIZE: =
11pt"><o:p><font face=3D"Times New =
Roman"> </font></o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0pt; margin-left: 0in; "><span =
style=3D"FONT-SIZE: 11pt"><font face=3D"Times New Roman">This e-mail may =
contain
information that is confidential, privileged or otherwise protected from =

disclosure. If you are not an intended recipient of this e-mail, do not =

duplicate or redistribute it by any means. Please delete it and any =
attachments
and notify the sender that you have received it in error. Unless =
specifically
indicated, this e-mail is not an offer to buy or sell or a solicitation =
to buy
or sell any securities, investment products or other financial product =
or
service, an official confirmation of any transaction, or an official =
statement
of Barclays. Any views or opinions presented are solely those of the =
author and
do not necessarily represent those of Barclays. This e-mail is subject =
to terms
available at the following link: </font></span><span lang=3D"EN-GB" =
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial; =
mso-ansi-language: EN-GB; mso-fareast-language: EN-GB"><a =
href=3D"http://www.barcap.com/emaildisclaimer">www.barcap.co m/emaildisclai=
mer</a>.
</span><span style=3D"FONT-SIZE: 11pt"><font face=3D"Times New Roman">By =
messaging
with Barclays you consent to the foregoing.<span style=3D"mso-spacerun: =
yes">  </span>Barclays Capital is the investment
banking division of Barclays Bank PLC, a company registered in =
<st1:place w:st=3D"on"><st1:country-region =
w:st=3D"on">England</st1:country-region></st1:place>
(number 1026167) with its registered office at <st1:address =
w:st=3D"on"><st1:street w:st=3D"on">1 Churchill Place</st1:street>, =
<st1:city w:st=3D"on">London</st1:city>, <st1:postalcode w:st=3D"on">E14 =

5HP</st1:postalcode></st1:address>.<span style=3D"mso-spacerun: =
yes"> 
</span>This email may relate to or be sent from other members of the =
Barclays
Group.<i style=3D"mso-bidi-font-style: =
normal"><o:p></o:p></i></font></span></div>
</font><div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: =
0pt; margin-left: 0in; "><font face=3D"Arial" size=3D"2"><span =
style=3D"FONT-SIZE: 11pt"><font face=3D"Times New =
Roman">_______________________________________________</font></span></font=
></div>
</div>
</blockquote></div><br><div>
<span class=3D"Apple-style-span" style=3D"border-collapse: separate; =
color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: 2; text-align: =
auto; text-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; ">-- <br>Wecos <> Heiko Weber Computer =
Systeme<br>D-21644 Sauensiek <> Immenweg 5<br><a =
href=3D"mailto:heiko [at] wecos.de">heiko [at] wecos.de</a> <> <a =
href=3D"http://www.wecos.de/">http://www.wecos.de</a><br>Tel. +49 (4169) =
91000 <> Fax +49 (4169) =
919033<br> ____________________________________________________________ ___<=
br>This email may contain confidential and privileged material =
for<br>the sole use of the intended recipient. Any review or =
distribution<br>by others is strictly prohibited. If you are not the =
intended<br>recipient please contact the sender and delete all =
copies.<br> ____________________________________________________________ ___=
<br>Diese E-Mail kann digital signiert sein. Falls Ihr =
E-Mail-Programm<br>nicht ueber die notwendigen Prueffunktionen verfuegt, =
ignorieren<br>Sie bitte die angehaengte =
Signatur-Datei.<br>_______________________________________________________=
________<br>This email may be digitally signed. If your email software =
does<br>not support the necessary validation feature, please disregard =
the<br>attached signature =
file.<br> ____________________________________________________________ ___<b=
r></div></div></div></span></span>
</div>
<br></div></body></html>=

--Apple-Mail-14-455376385--